Telecommunications Emergency Services (ES) include providing for or assisting with connecting a user of a wired or wireless telecommunication device to a geographically appropriate Public Safety Answering Point (PSAP) to provide emergency assistance to the user during their emergency situation. These ES capabilities may include but are not limited to, providing unrestricted, seamless, ubiquitous, and reliable end-to-end emergency session access between the user terminal/Mobile Station (MS) and the appropriate PSAP, geographically appropriate PSAP determination based on the current location of the terminal/MS, terminal/MS location determination assistance, terminal/MS location callback assistance, and emergency communication traffic priority and high-quality network resource reservation over non-emergency communication traffic.
Providing the various networking functionality, systems, and infrastructures to support the aforementioned ES features has been largely met for wired and wireless circuit switched based communications. However, with the emergence of new packet data (i.e. IP-based/enabled) networks, infrastructures, and services, these new technologies present many challenges in order to provide the same level of unrestricted, seamless, ubiquitous, and reliable end-to-end infrastructure for ES that is available today for circuit switched communications.
Some of these said challenges have been met in a limited sense, particularly for certain IP-based Emergency Services that are managed closely by or directly associated with an IP-enabled Access Service Network (ASN) and/or Connectivity Service Network (CSN) for which the terminal or MS is subscribed and/or associated with. Certain methods are in use or currently being designed and deployed to assist with this limited IP-based ES support.
IP-based rule hotlining is one method being used or in deployment to assist with IP-based ES support. Rule based hotlining provides a method for a network to restrict the network access of a terminal/MS to just a limited set of destinations. In the case of ES, rule based hotlining can be used to restrict a terminal/MS that is not subscribed or authenticated for network access over the ASN and/or CSN to still receive network access for ES. Alternatively, rule based hotlining can restrict the terminal/MS in an emergency mode of operation, for transmitting and receiving non-ES related traffic that may impact the ability to maintain the ES in use that triggered the ES hotline to the terminal/MS in the first place.
High Quality-of-Service (QoS) Service Flow (SF) establishment is another method being used or in deployment to assist with IP-based ES support. High QoS SF establishment provides a method for a network to guarantee a certain level of performance to a data flow associated, or classified, with the established SF. For ES, QoS guarantees are important if the network capacity is limited by static or dynamic network conditions. If a high QoS SF is established for a terminal/MS in an emergency situation where the network is under heavy loading relative to the capacity of the network to meet the required quality needs of the ES, a high QoS SF can be established to classify and prioritize the communication traffic associated with the ES in use by the terminal/MS.
In both the cases of rule based Hotlining and high QoS SF operation, a trigger request to configure and establish these methods, whether for ES or non-ES traffic, must be well trusted in order to prevent malicious use of these tools for theft-of-service, denial-of-service attacks, identity theft, and general data theft. This trust is dependent on the relationship and association between the network entity executing the operation (e.g. the ASN or CSN) and the network entity originating the operation request or forwarding it as a proxy on behalf of the originator or anther proxy.
A service can be classified into two categories. The first category is a service that is directly associated with the network element executing an operation, say the ASN for sake of example, on behalf of the service requesting it. This direct association may result from the fact that the service is owned and fully managed by the ASN so the trust can be implied since the ASN is responsible for both the trigger and the execution of the operation being requested. The said direct association could also result from a service agreement between the ASN and the provider of the service so that the trust is agreed upon and assumed as terms of the service agreement by the ASN performing the operation and the provider of the service sending the operation trigger. For this first category of services, it is relatively easy today for a strong trust relationship to be established between the service and the serving ASN, given the said direct association between these two elements, to determine the validity of a request, such as a QoS SF or hotline operation request, to be performed by the ASN on behalf of the service and terminal/MS utilizing the service.
The second category of a service is one which is neither directly associated with the network element executing the operation (e.g. the ASN or CSN) nor directly associated with an aforementioned service agreement. For this class of services, trust cannot be assumed by the ASN or CSN and thus must be determined programmatically. For this second category of services, it is today difficult to establish a strong trust relationship between the unassociated service and the serving ASN or CSN in order to determine the validity of a request to be performed by the ASN or CSN on behalf of the service and terminal/MS utilizing the service.
This second category of service can occur frequently in two different scenarios. The first scenario can occur when the user subscribes with an Application Service Provider (ASP) to an independent service with no association with the user's network (e.g. ASN/CSN) subscription that is used to access the service over the subscribed terminal or MS. One example of this scenario is a user who subscribes to an ASP IP-based VoIP service that does not provide network connectivity for the user to access the service. The second scenario occurs when the user is subscribed to a service that is directly associated with their home network provider but the user's terminal or MS is currently roaming on a visited network that does not have the necessary service agreement with the user's subscribed home network to create an association between the home network's services and the visited network.
Emergency Services in IP-enabled networks are impacted by these aforementioned trust limitations for an unassociated service in that, due to regulatory requirements and/or the altruistic desires of the ASN/CSN providers to provide unrestricted, seamless, ubiquitous, and reliable end-to-end ES capabilities, the ASN/CSN providers will need to take into consideration both the trust requirements for associated and non-associated categories of Emergency Services in order to provide capable ES support for both said categories of services while not compromising the ASN, CSN, and other network elements to the aforementioned risks that are possible with a malicious terminal/MS or ES.
In addition to the trust concerns for a non-associated ES, ASN and CSN providers must also take into consideration the trust issues that get introduced for both associated and non-associated services when the route of the control and/or data plane signaling between the execution point of the ES operation (e.g. ASN or CSN) and the trigger originator or proxy is altered or hidden through general common practice networking methods such as Virtual Private Network (VPN) tunnels, which can cause route tunneling, encapsulation, and/or encryption, Network Address Translation (NAT), deployed in network elements such as firewalls and Consumer Premise Equipment (CPE) routers for Small Office Home Office (SOHO) and other small local networks, and ASN/CSN roaming, where the terminal/MS may be attempting to access the home-network's associated ES but for which the ASN/CSN of the roaming network providing the general data connectivity does not have a direct or agreed upon relationship with the associated ES of the home network of the terminal/MS.